RLC protocol performance is governed by, among other factors, the RLC window size (WS). The window size of a protocol indicates how many blocks of data (blocks) that a transmitter can send without the need to receive acknowledgment information from the receiver. Both of the peer RLC transmitter and receiver have an RLC transmit and an RLC receive window, respectively, of size WS. At any given time, there may be at most WS outstanding blocks in the transmit (receive) window. As an example, a window of size WS=1 implies the transmitter can only send one block at a time, and that an acknowledgment from the receiver is required after each transmitted block before the transmitter can send the next block. A window of size WS=64 implies that the transmitter can send up to 64 blocks without receiving an acknowledgment from the receiver. Hence the larger the window size, the larger is the effective data rate. Typically, a good balance between the window size, the maximum rate at which blocks are sent/received, and the available (radio) resources that the protocol can use is needed to ensure optimum data throughput of the protocol.
In the General Packet Radio Service (GPRS) RLC a WS=64 is available. However, a problem can arise when the amount of used radio resources becomes high (e.g., when four or more timeslots are used) and when the round-trip delay on the RLC layer is relatively long. For example, it may take up to about 200 ms before an acknowledgment for a transmitted block is received. Under such conditions transmit window stalling regularly occurs (i.e., no new blocks can be sent, as all blocks within the transmit window have already been transmitted). This problem is overcome in the Enhanced GPRS (EGPRS) RLC, which allows for defining the window size as a function of the number of allocated timeslots.
A disadvantage of the use of a large window size is the inherent need for a large acknowledgment bitmap. Ideally, the receiver should be able to send one acknowledgment bitmap that covers the entire receive window. In the acknowledgment bitmap there is one bit allocated per block in the WS, with each bit indicating the success or failure of the error-free reception of the corresponding block. However, a large acknowledgment bitmap may not fit within one RLC/MAC (Medium Access Control) control block. To this end a rather complex technique using bitmap compression and network-controlled partial bitmap reporting was introduced for EGPRS RLC, as well as the occasional dropping of channel quality reports from the mobile station.
The introduction of a new physical layer (flexible layer one) in the Global System for Mobile Communication/Enhanced Data rates for GSM Evolution (GSM/EDGE) Radio Access Network (GERAN) has motivated the need for a definition of new values for RLC parameters to allow for optimum RLC performance, while avoiding GPRS limitations with multislot transmission schemes and EGPRS complexity for acknowledgments.
In the prior art the network commands the mobile station to send either first partial bitmaps or next partial bitmaps, with or without channel quality reports, even in those cases where the RLC receiver (the mobile station in a downlink (DL) data transfer) may have better insight as to which partial bitmap(s) should be sent.
However, the data transfer could be also to the opposite direction (on the uplink (UL) from the mobile station to the network). In this case the current specifications allow either first partial bitmaps or next partial bitmaps to be sent, but the strategy to be used in this context has not been determined.
As was noted above, in EGPRS the problem of accommodating extensive acknowledgment information in one RLC/MAC control block was addressed by a combination of network-controlled partial bitmap reporting, bitmap compression and dropping channel quality reports occasionally from the acknowledgment message. These mechanisms are defined in 3GPP TS 44.060 §§ 9.1.8.2 and 9.1.10. However, these approaches do not provide an optimum solution.